CloudFormation Metadata Context validation - #307

Summary

Adds validation for the CloudFormation Metadata Context convention (Metadata.com.aws.cloudformation.Context) at template and resource level. Three Engine-origin BestPractice rules run through one shared post-engine pass, so the rego, cel, and composite selectors produce identical diagnostics.

Rules

• I4010 — missing Context. Reports architecture-relevant resources without a Context block. When two or more resources lack Context, it also reports a template-level architecture summary as missing.
• W4011 — missing rationale. Reports a supplied resource Context block with neither a non-empty literal why nor a literal trust.conf: low declaration.
• W4012 — schema violation. Validates every supplied template and resource Context block against the published Metadata Context v1 schema and emits one diagnostic per invalid field.

All three rules are registered with RuleOrigin::Engine. Their IDs are stable engine rule IDs; behavior is derived from the published CloudFormation Context schema and this validator's diagnostics contract.

Shared Context validation

validation-engine/src/context_check.rs runs after the selected engine evaluates its rules and before normal diagnostic finalization. The shared pass:

• Applies global rule, category, strict-mode, and severity suppression before doing Context work. Resource-scoped filters are applied before I4010 aggregation.
• Loads and parses the embedded schema lazily, only when W4012 is active and a Context block is present.
• Orders resources by precomputed source coordinates without allocating logical-ID sort keys.
• Reads authored CloudFormation JSON for template and resource Context so diagnostics preserve intrinsic names and authored paths.
• Rejects intrinsic functions everywhere inside Context. Ref and canonical Fn::* objects produce explicit W4012 diagnostics; transformed-resource fallback markers are canonicalized and never expose internal __intrinsic names.
• Avoids a duplicate/misleading W4011 when the whole Context block or a rationale-bearing value (why, trust, or trust.conf) is itself an intrinsic; W4012 reports the invalid intrinsic directly.
• Allows arbitrary property names in mutability as the schema requires, including a property named Condition, while still recognizing Ref and canonical Fn::* keys as invalid intrinsic functions.

A resource with a usable Type requires its own Context block unless it is a subordinate resource type (AWS::IAM::Policy, AWS::Lambda::Permission, AWS::Logs::LogGroup, AWS::Logs::LogStream, AWS::S3::BucketPolicy, AWS::SNS::TopicPolicy, or AWS::SQS::QueuePolicy), a ::MODULE, or AWS::CDK::Metadata. Known CDK framework helpers are skipped by logical ID. Context supplied on an exempt resource is still validated by W4011 and W4012.

Missing resources are aggregated into one I4010 diagnostic anchored at the first resource and list every missing LogicalId (Type); remaining resources are attached through relatedResources with their source spans. Schema violations are located at the invalid field. The checks intentionally also run on CDK-synthesized templates, while AWS::CDK::Metadata and known framework helpers remain exempt.

Validation behavior

Expected behavior comes from the Metadata Context documentation and schema:

• TemplateContext permits arch, must, ref, and owner.
• ResourceContext permits why, must, mutable, mutability, trust, and deps.
• Both reject undefined fields and values that do not directly match their declared schema shapes, including intrinsic-function objects.

Checklist

• Expected behavior is supported by the published CloudFormation Context schema.
• Rego, CEL, and Composite selectors agree across the complete corpus.
• Existing snapshot values are unchanged; new behavior has focused fixtures and integration coverage.
• The code follows the contributing and design guidelines.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.